In banking applications, there are many levels of data production and analysis. Concurrent with the growth of banking applications, including accounting software systems, there has been the growth of additional requirements on the users and the financial data itself. For instance, as the account principles grow, such as found with Generally Accepted Accounting Principles (GAAP), there are further demands on the financial data. In another example, regulatory bodies for certain types of users have increased the accounting demands, such as found with the Sarbanes Oxley regulations, commonly referred to as SOX.
The multi-component banking/financial software processing systems include different functionalities that produce data specific to the associated functions. Additionally, these systems then store and are capable of performing further analysis on this data. For example, an invoice application may collect various accounting data and thereupon assemble a time-specific spreadsheet such as a balance sheet.
This same exemplary processing application may save this data as well as the generated work product. By way of sample nomenclature, the application may save this data as historical data. In the accounting processing system, memory locations are designated to store this specific historical data.
In the normal course of operation, the invoice application may readily access this historical data. The data, while stored in the central location, is significantly restricted to the invoice application or applications directly associated therewith. For example, directly associated applications may include a more general application that includes the invoice application functionality. But the nature of the current financial and banking operating systems is that this data is not available outside of this specific usage based on its creation by the application.
In these banking applications, stored data becomes formatted or contextually associated with specific applications due to the nature in which the data is generated and stored in the system. Using the example of the invoice application, the data is processed and thus formatted relative to the invoice application.
Thereupon, for this data to be usable in another application or system, the data must be converted. Typically, this process requires one of two techniques. A first technique is to generate a specific translation between the original application and a format usable by the second application. A second technique includes translating the data to a generalized format and then translating again to the format usable by the second application.
In the first technique, this requires a specific translation or interface between these two applications. The second technique similarly requires the development of translators between the various data encodings. Both techniques are expensive and time consuming. In current banking applications, significant valuable resources are employed using the above techniques to make the data available between systems. This not only reduces computational ability of the banking system, but also significant reduces the variety of cross-data analysis operations.
By way of a specific example, under the current banking applications, a user would find it extremely difficult to utilize existing invoice data for a secondary analysis of financial risks. For example, in invoice information there may be the requisite information for performing the analysis to calculate a party's credit risks. Under existing systems, the invoice data would have to be fully translated between the invoice application encoding to be made available for a credit risk analysis. This would require one or more levels of translation and this procedure would be applicable only to the data itself. Should the credit risk analysis require further information from other applications, such as possibly from an account balance system, this data would also require full translation.
Therefore, under the current system, the data is essentially unusable outside of the base application or functionality that created it. As further demands are placed on accounting information by not only users but also regulatory (e.g. SOX) requirements, current systems are unable to efficiently use existing data for additional process operations or calculations outside of the original use.